First, the storage stuff seems counter-intuitive; we'd have to add an implementation for each backend supported by PDO, so that needs fixing.

Second, since TAL templates must be valid XML, we shouldn't parse them using regular expressions, but use DOM instead.

Unfortunately the PDO execute query API varies slightly between Sqlite and Mysql hence the need for the extra handlers.

Also regarding the tal, php can also be executed within the content of an element so it would need some pcre patterns anyway.

Thus the implementation I made seemed to be sufficient although perhaps not optimal.

This modification was done some time ago so having taken another look it seems that there was perhaps a bug in the use of executeQuery() instead of query() for initialisation queries on the PDO connection. So actually all the Mysql support could be handled just by making the table construction commands configurable.

Go for it :p

I realize PHP can be executed inside, but that's not a reason not to parse the overall stuff properly :)

My main concern with using the PHP DOM is the poor character set handling. It always represents internally as UTF-8 which will cause issues with content in other character sets such as EUC-JP. :(

That's not poor handling, @MrHash, but in line with the DOM specification :) It always converts to UTF-8. That's what makes DOM portable - no matter what encoding your document is in, the content is represented in Unicode's UTF-8 encoding, so you don't have to figure out how to convert things anymore. It's supposed to be like that :)